A Flight Simulator for Atf2 - a Mechanism for International Collaboration in the Writing and Deployment of Online Beam Dynamics Algorithms*†

The goals of ATF2 are to test a novel compact final focus optics design with local chromaticity correction intended for use in future linear colliders. The newly designed extraction line and final focus system will be used to produce a 37nm vertical waist from an extracted beam from the ATF ring of ~30nm vertical normalised emittance, and to stabilise it at the IP-waist to the ~2nm level. Static and dynamic tolerances on all accelerator components are very tight; the achievement of the ATF2 goals is reliant on the application of multiple high-level beam dynamics control algorithms to align and tune the electron beam in the extraction line and final focus system. Much algorithmic development work has been done in Japan and by colleagues in collaborating nations in North America and Europe. We describe here development work towards realising a 'flight simulator' environment for the shared development and implementation of beam dynamics code. This software exists as a 'middle-layer' between the lower-level control systems (EPICS and V-SYSTEM) and the multiple higher-level beam dynamics modeling tools in use by the three regions (SAD, Lucretia, PLACET, MAD...). OVERVIEW OF THE FLIGHT SIMULATOR PROJECT The main goals of the flight simulator project can be summarised as follows: * Provide a simple to use, beam dynamics oriented, portable control access framework for ATF2 tuning tasks. * There should be simple and reversible transition from beam dynamics simulation to accelerator-ready code. * Provide the ability for international collaborators to develop beam tuning tools without the need for expertlevel knowledge of control systems. * Allow the flight simulator to operate in simulation mode at an external location in the same way as the production system deployed at ATF2. Another key difference between the interface offered by the flight simulator to that of the standard control system is that it provides a mechanism to automate multiple beam tuning tasks. Through a common interface, it is left to the user to decide which accelerator code best suits his or her needs. The flight simulator software thus forms a management package which allows beam dynamics code written in a variety of environments to interact. The main concentration of effort for this project is to address the tuning tasks of the ATF2 extraction line and final focus system. However, the extension of the project to include beam physics tasks in the Damping Ring is also envisioned for the future. COMPONENTS OF THE FLIGHT SIMULATOR The core functionality of the flight simulator software is written as a library of Matlab functions which extends the functionality of the Lucretia accelerator toolbox [1]. Lucretia contains many functions useful for the simulation of single-pass electron beamlines and has been used extensively in the modelling of ILC. It was written to provide the user with an interface very much like one would use at an operational accelerator installation. As such it lends itself well to being used in the fashion described here. The flight simulator can be described as a 'middle-layer' between the lower-level control system interface and the beam dynamics simulations and algorithmic development performed by physicists. By providing a portable system that behaves in the same way in 'simulation mode' as the production version at the accelerator, it is possible to develop code in an environment that the user is used to and can be run on the real machine with little or no alteration. It is also possible to develop a final version of the beam dynamics code without direct access to the production control system which has security benefits. The pre-existing Lucretia data structures are used to hold the real-time data. The design model values are kept in the BEAMLINE array, and real-time modifications in the PS (power supply), GIRDER (movers) and INSTR (BPMs and other monitors) arrays. A schematic representation of the flight simulator and its installation into the ATF control system environment is shown in figure 1. At the lowest level of the system are the Input-Output Controllers (IOCs) that read and write data to the beamline hardware systems. For many of the new hardware systems these are EPICS-based IOCs running on a mixture of VME, CAMAC and PC-based architectures. The re-used and existing IOC systems from ATF are based on the V-SYSTEM control architecture. An additional 'soft' EPICS IOC has been written to generate EPICS Process Variables (PV's) that synchronise to the control variables in V-SYSTEM. The flight simulator *work supported in part by Department of Energy Contract DE-AC02-76SF00515 †work supported in part by the Commission of the European Communities , contract number RIDS-011899 SLAC-PUB-13304 July 2008 Contributed to the 11th European Particle Accelerator Conference (EPAC08), 7/23/2008 to 7/27/2008, Genoa, Italy implements its hardware read-write functions through an EPICS Channel-Access (CA) client interface. The flight simulator software itself exists as two installations. The “trusted” installation has read/write access to EPICS and runs applications that have been well tested and as such are integrated into the control system proper. The other installation is the “test” installation. This typically runs on a users personal computer. A server-client relationship thus exists between the trusted and test installations. The user writes applications in the test environment, and to gain access to the control system PV's that it needs to run, it must request access rights from the server which then handles read/write requests. “Trusted” Installation Functionality The core functions of the flight simulator server software are listed here: Server-client communications: A tcp socket implemented in java natively in the Matlab environment is used for communications between the “trusted” server and “test” client. The server constantly listens out on a tcp socket and assigns new ports to inbound requests, thus allowing the possibility of multiple simultaneous connections. Access control to client installations: By default the “test” client has no write access to any control variable. Using one of the built-in flight simulator functions, it must request access for all the PV write-access it needs to run a given application. Each new request from a client appears on a window on the computer running the server. An operator must then grant permission for the PV access. This way, full control is maintained over which systems are being used at any time avoiding problems with multiple simultaneous control requests and providing an additional layer of security to the control network. Server-based data services: Where tested applications exist, they are available through the flight simulator interface to be called from the server. An example is BPM averagingit is possible to call the averaging function from the client and the server will run the application and return the averaged readings, with optional quality cuts. Sync. Control system with Lucretia model: The server updates it's internal Lucretia model of ATF2 at the machine rep. rate of 1.56 Hz. It has internal look-up tables to translate the raw control system values (magnet currents etc) into the values used by Lucretia. The server connects to the EPICS databases through labCA [2]an EPICS CA client written for Matlab. Maintain updated AML and Lucretia models: The two model definition standards supported by the flight simulator are the native Lucretia model data (binary matlab .mat files) and AML. Both files are periodically written to disk, with the intention of making these available on a public server so a user can obtain the current state of the machine at any time from any location. It is also planned to implement an archive function, such that the running state of the machine at any given time can be obtained which should prove very useful for post-mortem diagnostics. Provide PS setting and magnet move functionality through native Lucretia functions (PSTrim, MoverTrim): The way of making changes to the accelerator (namely, power supply changes and magnet mover settings) is through the usual native Lucretia functions, with additional complexity necessary to deal with access from the server or client hidden from the user. “Test” Installation Functionality The client flight simulator, installed on a user's laptop for example, is effectively the same software environment as the server. It contains a local version of the ATF2 lattice and settings in it's own Lucretia model. On startup, it initiates a link to the server through a tcp socket connection. It initially loads the default lattice, but then can synchronise it's Lucretia database with that of the server's automatically or at the users request. There is a common directory structure between the 2 installations; test applications and certified trusted applications exist in separate folders. Both are available to the client, but only the trusted applications are available to the server which runs on the control system proper. The client then has the full functionality of the Lucretia toolbox which can now be operated on with a live version of the ATF2 machine state. However, access to write to PS (power supply) and GIRDER (magnet mover) elements is restricted initially and access must be specifically granted by an operator through the server interface. To enable the use of other accelerator codes within this same framework, the client also runs an additional tcp socket server. This is implemented in an identical way to the other flight simulator server socket. This client-side server processes ascii commands from a source on the localhost. In this way, another accelerator code has access to the full functionality of the flight simulator as long as it can implement a tcp socket client. The flight simulator supports the AML deck standard [3] through the use of Lucretia2AMLcode written using UAP (Universal Accelerator Parser) to synchronise the Lucretia model with an AML file. This serves as the entry-point for an external accelerator code package. Further updates and access/read/write requests are performed through the flight simulator client socket server process. Through the use of a shared data structure on the flight simulator client program, it is possible for sharing of data and application processing between Lucretia and other accelerator codes. Figure 1: Implementation of the Flight Simulator at ATF